# Customer Identity & Authentication

## Identity

Your Form, your Customers. Learn how to link response identity with your existing user records.

### Method 1. Provide customer uuid via hidden field

Add a hidden input field to your form with the name `__gf_customer_uuid` and the value of the customer's unique identifier.

```html
<form>
  <input type="hidden" name="__gf_customer_uuid" value="123456" />
  <input type="text" name="name" placeholder="Name" />
  <input type="email" name="email" placeholder="Email" />
  <input type="tel" name="phone" placeholder="Phone" />
  <button type="submit">Submit</button>
</form>
```

Or via url parameter (hidden field configuration is required)

```txt
https://forms.grida.co/d/e/xxx?__gf_customer_uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
```

### Method 2. Provide customer uuid via SDK

> This feature is under development. if you wish to access this feature, please contact us

```tsx
import { Agent } from "@base-sdk/forms";

const agent = new Agent({
  apiKey: "YOUR_API_KEY",
  formId: "YOUR_FORM_ID",
  customer: {
    uuid: "CUSTOMER_UUID",
  },
});

const Form = () => {
  const handleSubmit = async (e) => {
    e.preventDefault();
    await agent.submit({ e });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="text" name="name" placeholder="Name" />
      <input type="email" name="email" placeholder="Email" />
      <input type="tel" name="phone" placeholder="Phone" />
      <button type="submit">Submit</button>
    </form>
  );
};
```

## Authentication

Customers in Grida can either be manually populated by the user or auto-generated by the system. To provide flexibility and clear responsibility boundaries, Grida supports the following authentication methods:

### Supported Authentication Types:

- **Password (Document Protection)**  
  Protects individual documents with a password (similar to PDF password protection). Does not authenticate the customer but authorizes document access.

- **Email Magic Link**  
  Sends a secure, one-time login link via email, using the customer's `email` field.

- **Email OTP**  
  Sends a one-time passcode via email, using the customer's `email` field.

- **KBA (Knowledge-Based Authentication)**  
  User-defined challenges based on custom customer model fields. Users have complete responsibility for defining secure questions/answers or other identifiers. Note: This method is inherently less secure (Weak KBA).

### Unsupported Authentication Types:

- **Basic Auth** (username/password)
- **API Key** (automation)
- **Bearer Token** (token-based authorization)
- **SSO** (Single Sign-On with Okta, Auth0, etc.)

### Configurable Security Features (User Responsibility):

- **reCAPTCHA:** Protect forms from bots and automated attacks.
- **Rate Limiting:** Restrict the number of authentication attempts within a given time frame.
- **Trusted IP/Origin:** Allow access only from specific IP addresses or origins.

### Device Fingerprinting:

Grida tracks device fingerprints for analytics and user identification purposes when authentication is not enabled. Note: Device fingerprinting is not reliable or acceptable as a standalone authentication factor and is used only for improved analytics and customer identification accuracy.


## Important: Handling Duplicate Identifiers

When using identifiers like email in your authentication flows—whether custom or built-in—please be aware that these values might not be unique if customers are populated manually. For instance, if multiple customers share the same email address, the authentication process might reject the login attempt.

**Action Required:**  
Ensure that each customer record is associated with a unique identifier or implement a duplicate resolution strategy (e.g., selecting the most recently created customer with an active subscription). This check is essential to avoid ambiguous authentication scenarios and ensure a smooth user experience.